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(54) Addressing scheme to be used in an IP-based radio access network 



(57) The invention relates notably to an addressing 
scheme to be used in an IP-based Radio Access Net- 
work. 

According to the invention, the addressing scheme 
consists in that the radio channel type over which a base 



station communicates with an end-user radio terminal 
is univocally determined by a port number value men- 
tioned in each TCP or UDP data packet exchanged over 
the Radio Access Network and belonging to a commu- 
nication with the end-user radio terminal. 
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Description 

[0001] The present invention relates to radio commu- 
nication systems and more particularly to an addressing 
scheme to be used in an IP-Based Radio Access Net- 
work. 

[0002] In an usual radio communication network, a ra- 
dio terminal has access, over a radio interface, to a Ra- 
dio Access Network which is the dedicated infrastruc- 
ture to set up and control connections between the radio 
terminal and different other possible end-users, for ex- 
ample another radio terminal, a fixed terminal, or a web 
server. 

[0003] A Radio Access Network is mainly composed 
of base stations and of their controller. End-user data 
and connection-control data are conveyed over the Ra- 
dio Access Network between these network elements. 
[0004] In the case of usual GSM mobile radio com- 
munication networks, the Radio Access Network is tai- 
lored to the GSM standard with for example permanent 
connections between a base station and its controller. 
[0005] In third generation radio communication net- 
works, as UMTS for example, it proves more appropri- 
ate to use a de-facto standard network (e.g. an ATM or 
IP network) as underlying transport capability in the Ra- 
dio Access Network instead of a Radio Access Network 
specifically tailored for the radio communication net- 
work. This enable to reuse the recent enhancements in 
term of performance and quality of service that have 
been achieved and keep being improved in the field of 
IP or ATM transport. To adapt these de-facto standard 
networks to the specific requirements of a Radio Access 
Network, specific layers have to be implemented above 
the IP or ATM transport layers. 

[0006] Figure 1 represents an example of an IP Back- 
bone network used as transport layer of a Radio Access 
Network in an UMTS radio communication network. 
Base stations in an UMTS radio communication network 
are called Node Bs and base station controllers are 
called Radio Network Controller RNCs. Several base 
stations 101, .... 104 as well as several RNCs 111, 112 
are considered as hosts of the IP-based Radio Access 
Network and are connected to each other over intercon- 
nected edge routers 121,..., 124 and core routers 
131, 133. The interconnection of edge 121, 124 
and core 131, 133 routers constitutes the IP back- 
bone. 

[0007] The most important task of the Radio Access 
Network consists in enabling communications between 
a base station and its corresponding RNC (luB interface) 
as well as communication between several RNCs (lur 
interface). In an IP-based Radio access network, these 
communications can made up of several hops, several 
edge routers or core routers relaying the communication 
between two hosts. 

[0008] In such an IP-based Radio Access Network, 
the physical links between the different routers can mix 
several technologies. Transport functions, like address- 



ing and routing, are made according to IP de-facto 
standard. All elements of the Radio Access Network (e. 
g. base stations 101, 104, RNCs 111, 112, routers 
121, .... 124 and 131 133) are assigned an IP ad- 

5 dress and can be addressed univocally with this IP ad- 
dress. The IP layer of the IP-based protocol stack is re- 
sponsible for transferring data between hosts. 
[0009] A protocol layer, set above the IP layer, is re- 
sponsible for differentiating among multiple data sourc- 

10 es and destinations within one single host. These differ- 
ent sources or destinations may be different concurrent 
applications. This is required by parallel processing and 
multitasking performed at base stations or base station 
controllers having a high processing power. 

is [ooi 0] An example of such a layer in the I P-based pro- 
tocol stack is UDP (User Datagram Protocol), another 
example could be TCP (Transmission Control Protocol). 
UDP or TCP provide both two services not provided by 
the IP layer. They provide port numbers to help dislin- 
20 guish different sources and destinations inside a single 
host and, optionally, a checksum capability to verify that 
the data arrived intact. 

[0011] In the Open Systems Interconnection (OSI) 
communication model, IP correspond to Iaycr3, the net- 
25 work layer. UDP, like TCP, is in layer 4, the Transport 
Layer. The User Datagram Protocol is specified by In- 
ternet Engineering Task Force (Request for Comments 
768). 

[0012] This invention concerns the adaptation of an 

30 IP-based Radio Access Network to specific require- 
ments of a radio communication network. One of these 
specific requirements is that the pure radio part of the 
radio communication network is not supported by usual 
IP de-facto standards. 

35 [0013] The radio part of a radio communication net- 
work supports for example different channel types. A 
first category of these channel types is dedicated chan- 
nels (e.g. dedicated traffic channels DTC) which are at- 
tributed to exclusively one communication. Another cat- 

40 egory of radio channel types is common channels. 
These radio channels multiplex data belonging to sev- 
eral connections or data shared by several connections. 
Examples of common channel types are random access 
channel (RACH) or broadcast channel (BCH). This is 

45 not an exhaustive list of all possible channel types. The 
complete list of different channel types is radio commu- 
nication network dependant and is described in the radio 
interface specification of each radio communication 
channel. 

50 [0014] The possibility to distinguish between several 
channel types is not given in the IP de-facto standard. 
A protocol conversion has to be implemented between 
the IP-based Radio Access Network and the radio part 
of the radio communication network to remedy to this 

55 problem and ensure the interworking between the IP- 
based Radio Access Network and the radio part of the 
radio communication network. This protocol translation 
takes preferably place at the edge of the Radio Access 
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Network (e.g. in the base stations or in the base station 
controller). 

[0015] A method for solving this problem has already 
be provided in ATM-based Radio Access Networks and 
consists in using the signaling plane specified in the 
ATM de facto standard to convey the radio part specific 
parameters. The user data are in parallel conveyed 
through a connection established between the base sta- 
tion and the RNC. However, contrary to ATM, basically 
connection oriented, IP is basically connectionless and 
do not provide any signaling plane. 
[0016] As a consequence, each additional communi- 
cation parameter has to be conveyed by adding a field 
in the payload of IP packets exchanged in the IP-based 
Radio Access Network. This further field containing the 
further communication parameter (e.g. the type ot chan- 
nel on which this information has to be mapped on the 
radio part of the network) is possibly part of the header 
of a communication entity encapsulated in the UDP 
packet. 

[0017] A drawback of this method would be to add 
overhead and slower the transmission as well as the 
processing delay. This is all the more problematic as 
keeping the delays, while crossing the network, as small 
as possible is vital for ensuring an acceptable quality of 
service. This method has also the disadvantage to re- 
duce the data throughput at the interface between the 
Radio Access Network and the radio interface. 
[0018] A particular object of the present invention is 
to provide an addressing scheme that do not require a 
separate signaling plane for signaling the type of radio 
channel on which data destined to a radio terminal have 
to be transported on the radio interface. 
[0019] Another object of the present invention is to 
save the use of a further a field for explicitly specifying 
the radio channel type to be used for transmitting the 
corresponding data over the air interface. 
[0020] These objects, and others that appear below, 
are achieved by an addressing scheme to be used in an 
IP-based Radio Access Network, the Radio Access Net- 
work comprising a plurality of base stations and at least 
one base station controller, all communicating with each 
other by using an TCP/IP- or UDP/IP-based protocol 
stack, each base station being dedicated to communi- 
cate with a plurality of radio terminals having access to 
the Radio Access Network over at least two different 
types of radio channels. The addressing scheme con- 
sists in that the type of radio channel over which the 
base station communicates with one of the radio termi- 
nals is implicitly and univocally determined by a port 
number mentioned in each TCP or UDP data packet ex- 
changed overthe Radio Access Network and belonging 
to a communication with the radio terminal. 
[0021] This method has the advantage to reduce the 
overhead necessary for the protocol translation be- 
tween an IP-based Radio access network and the radio 
part of the communication network. 
[0022] The present invention also concerns a base 



station according to claim 6 and a Radio Network Con- 
troller according to claim 8. 

[0023] Other characteristics and advantages of the in- 
vention will appear on reading the following description 
5 of a preferred implementation given by way of non-lim- 
iting illustrations, and from the accompanying drawings : 
in which: 

Figure 1 shows a physical architecture of a IP- 
1 ° based Radio Access Network; 

Figure 2 shows the principle of the addressing 
scheme according to the present invention. 

[0024] Figure 1 has already been described in relation 
*5 with the technical problem underlying the present inven- 
tion. 

[0025] . UDP will be preferred to TCP in the following 
as it better suits the delay requirements of a Radio Ac- 
cess Network than TCP. Unlike TCP, UDP does not pro- 

20 vide the service of dividing a message into packets (da- 
tagrams) and reassembling it at the other end. Specifi- 
cally, UDP doesn't provide retransmission of packets. 
These specific TCP features badly influence the end-to- 
end delay in the Radio Access Network. 

25 [0026] However, the addressing scheme described 
above could also apply in an IP-based protocol stack 
using TCP since TCP as UDP use the concept of port 
numbers. 

[0027] Figure 2 represents an IP packet exchanged 

30 in an IP-based Radio Access Network and illustrates the 
addressing scheme according to the invention. In the 
OSI communication model, the IP-based protocol stack 
relies on encapsulation of a communication unit belong- 
ing to a certain layer in a protocol unit belonging to the 

35 layer just beneath. IP packet 20 comprises an IP packet 
header 21 and an IP packet payload 22. The IP packet 
payload 22, inturn, encapsulates an UDPmessagecon- 
sisting of an UDP header 23 and of a UDP payload 24. 
UDP payload 24 encapsulates a radio part specific mes- 

*o sage. The header 25 of this message comprises inter 
alia the reference of the end-user radio terminal to 
which, respectively from which, this message is des- 
tined, respectively received, and the payload 26 of this 
message contains the end-user data. The reference of 

45 the end-user radio terminal consists preferably on an 
address referencing the end-user radio terminal. This 
address is unique in the area of the base station to which 
the end-user radio terminal is attached. 
[0028] The UPD header 23 is, as specified in the IETF 

so standard, divided in four two bytes fields that specify fol- 
lowing parameters: 

the port from which the UPD payload has been is- 
sued (source port number SPN); 
55 - the port to which the UDP payload is destined (des- 
tination port number DPN); 
the UPD payload length L; and 
a UDP payload checksum CRC. 
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[0029] The destination port number is used to demul- 
tiplex correctly the IP packet and forward each UPD pay- 
load to the application corresponding to the destination 
port. Usually, the source and destination port are only 
internally used in a host (e.g. base station or RNC). A 
pool of port numbers are reserved for concurrent appli- 
cations performing in parallel an identical task. In usual 
use of the UDP protocol, the port numbers are thus ei- 
ther randomly allocated to an application when it is ac- 
tivated or according to a round-robin algorithm. 
[0030] This invention consists, contrary to the random 
port number allocation described above, in managing 
the pool of available port numbers in a way that each 
port number is no more only used for internal processing 
at the host but also conveys an indication regarding the 
radio channel type over which the data have to be trans- 
mitted, respectively the radio channel type from which 
the data were received. For this matter, the pool of port 
numbers is divided in several groups of port numbers, 
each group being exclusively used for processing data 
to be transmitted or received over one predefined type 
of radio channel. 

[0031 ] The pool of port number as well as the assign- 
ment of one group of port numbers to one channel type 
may preferably be the same for each host in the Radio 
Access Network. 

[0032] A first group of port number should be used for 
data to be transmitted over a first channel type after pro- 
tocol translation at the base station. A second group is 
used for data to be transmitted over a second channel 
type and so on... 

[0033] Each group should at least comprise one port 
number. As already mentioned, the exact number of 
channel types have to be extracted from the radio inter- 
face specification of the considered radio communica- 
tion network. 

[0034] The destination port number in the UDP head- 
er is used to make the association port number, channel 
type to be used on the radio interface. It could also be 
envisaged to use the source port number in the UDP 
header to make this association. A choice between the 
use of the one parameter or of the other parameter has 
to be made. 

[0035] The dimensioning of the different groups 
should be done in such a manner that it balances and 
optimizes the load on each available port number. The 
mapping between available port numbers and corre- 
sponding channel types on the radio interface may be 
a system parameter initialized at initialization of the Ra- 
dio Access Network so that each base station or RNC 
is informed of it. 

[0036] This mapping may, in another embodiment, be 
dynamically updated according to the needs of the Ra- 
dio Access Network and communicated to the base sta- 
tions and the RNC once updated. An Operation and 
Management Center (OMC) part of the Radio Access 
Network may for example run statistics on the different 
traffic flows through the Radio Access Network and de- 



6 

termine an optimal mapping between the port numbers 
and the radio channel types. This update may.be done 
at constant time interval or according to any other up- 
date criterion known by a person skilled in the art. 
5 [0037] The correspondence between port numbers 
and channel types may be physically stored in a memory 
location or a database accessible for the base stations 
and the RNCs of the Radio Access Network. This mem- 
ory location may be centrally located in the network or 

10 distributed in the different hosts. 

[0038] Except the base stations and the RNCs, the 
other elements of the Radio Access network (e.g. the 
edge and core routers) pass transparently the destina- 
. tion port number contained in the UDP header without 

*5 modifying it. 

[0039] In the following, the use of this addressing 
scheme in an host of the Radio Access Network (base 
station or RNC) will be discussed in detail. 
[0040] A first part describes the use of the addressing 

20 scheme for data coming from the Radio Access Network 
at a base station and to be transmitted to a radio terminal 
over the radio interface. The base station identifies 
thanks to the UPD destination port number on which ra- 
dio channel type the data have to be transmitted. A field 

25 jn the UDP payload is also used to give the identifier of 
the end-user to which these data are destined. This 
identifier is unique for all end-user radio terminals be- 
longing to one base station. The association of the end- 
user identifier and the UDP port determines univocally 

30 the destination of the message to be transmitted on the 
air interface. 

[0041 ] The RNC is also responsible for protocol trans- 
lation. It receives usually a call identifier from the rest of 
the radio communication network and has to translate it 

35 in a format specific to the Radio Access Network. As a 
consequence, the call identifier is translated in a triplet 
comprising the IP address of the base station, the UDP 
destination port number and the end-user identifier. 
These parameters as well as the user data are then 

^o used to constitute an I P-packet to be sent over the Radio 
Access Network. 

[0042] A second part, describes the use of this ad- 
dressing scheme for data received from a radio terminal 
at a base station and to be transmitted to the Radio Ac- 
cess Network. The base station detects the radio chan- 
nel type on which these data have been received. It se- 
lects an available port number out of the memory loca- 
tion belonging to the group of port numbers assigned to 
the appropriate channel type. Then, the base station op- 

50 erates the protocol translation consisting in mapping the 
data format received from the radio channel to an IP 
packet. The destination port number field in the header 
of the encapsulated UDP packet is set to the value of 
the port number retrieved from the memory location. 

55 The radio part specific message encapsulated in the 
UDP packet contains in its header a field specifying an 
identifier of the end-user radio terminal at the origin of 
these data. This identifier in combination with the UDP 
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port number is unique in the area of a given base station. 
[0043] At base station, besides the pure protocol 
translation, shaping and multiplexing of several data 
flow may be done. As a consequence, the UDP packet 
may not only encapsulate one radio part specific mes- 
sage but a plurality of multiplexed radio part specific 
messages belonging to different users but having been 
received, respectively to be transmitted, on radio chan- 
nels having the same channel type. Several multiplexed 
radio part specific messages are called a container. The 
shaping consists in segmenting each radio part specific 
message according, for example, to different level of pri- 
ority assigned to the radio part specific message. 



Claims 

1. Addressing scheme to be used in an IP-based Ra- 
dio Access Network, said Radio Access Network 
comprising a plurality of base stations and at least 
one base station controller, all communicating with 
each other by using an TCP/I P-or UDP/IP-based 
protocol stack, each of said base stations being 
dedicated to communicate with a plurality of radio 
terminals having access to said Radio Access Net- 
work over at least two different types of radio chan- 
nels, said addressing scheme being characterized 
in that the type of radio channel over which said 
base station communicates with one of said radio 
terminals is implicitly and univocally determined by 
a port number mentioned in each TCP or UDP data 
packet exchanged over said Radio Access Network 
and belonging to a communication with said radio 
terminal. 

2. Addressing scheme according to claim 1 , charac- 
terized in each of said radio channel types is asso- 
ciated to at least one of said port numbers available 
at a base station or at a base station controller of 
said Radio Access Network,. 

3. Addressing scheme according to claim 1 . charac- 
terized in that said IP-based protocol stack used 
in said IP-based Radio Access Network comprises 
UDP/IP combination, the UDP destination port 
number in said UPD header determining univocally 
said radio channel type. 

4. Addressing scheme according to claim 1 , charac- 
terized in that said IP-based protocol stack used 
in said IP-based Radio Access Network comprises 
UDP/IP combination, the UDP source port number 
in said UPD header determining univocally said ra- 
dio channel type. 

5. Addressing scheme according to claim 1 , charac- 
terized in that the parameters of a communication 
with said radio terminal are defined by an IP ad- 
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dress, a UDP destination port number, and a com- 
munication identifier contained in the different lay- 
ers of said IP-based protocol stack used in said Ra- 
dio Access Network. 

Base station to be part of an I P-based Radio Access 
Network and communicating with other elements of 
said Radio Access Network by using an IP-based 
protocol stack, said base station being dedicated to 
communicate with a plurality of radio terminals hav- 
ing access to said Radio Access Network over at 
least two different types of radio channels, said 
base station being characterized in that it compris- 
es a channel type selector to determine the channel 
type on which data coming from said Radio Access 
Network have to be transmitted to one of said radio 
terminals, said channel detector determining univo- 
cally said channel type by means of a port number 
mentioned in the TCP or UDP header of a data 
packet received from said Radio Access Network 
and belonging to a communication with said radio 
terminal. 

Base station according to claim 6, characterized in 
that said channel selector further selects a port 
number to be used in said IP-based protocol stack 
to forward data to said Radio Access Network de- 
pending on the channel type on which said data are 
received from one of said radio terminals. 

Radio Network Controller to be part of an IP-based 
Radio Access Network and communicating with 
other elements of said Radio Access Network by 
using an IP-based protocol stack ; said Radio Net- 
work Controller receiving from outside of the Radio 
Access Network data belonging to a communication 
with a radio terminal, said radio terminals being ac- 
cessible over at least two different types of radio 
channels, said Radio Network Controller being 
characterized in that it comprises a channel type 
selector to determine, according to said data be- 
longing to said communication, the channel type on 
which a part of said data belonging to said commu- 
nication have to be transmitted to said radio termi- 
nal, said channel detector determining univocally. 
according to said channel type, a port number to be 
mentioned in each TCP or UDP data packet ex- 
changed over said Radio Access Network and be- 
longing to said communication with said radio ter- 
minal. 
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